IMO we should implement undo/redo instead. With undo/redo implemented, determining if the project has changed should be easy, and obviously it's also useful to be able to undo things.

We could theoretically implement the two features separately, but that means that undoing and redoing something will still make the project "dirty"

Current coverage is 48.01%

Merging #359 into master will decrease coverage by -0.25% as of 5d9e061

@@            master    #359   diff @@
======================================
  Files          124     125     +1
  Stmts         3698    3707     +9
  Branches       402     404     +2
  Methods          0       0       
======================================
- Hit           1785    1780     -5
  Partial        111     111       
- Missed        1802    1816    +14

Review entire Coverage Diff as of 5d9e061

Uncovered Suggestions

1. +0.73% via ...loyerController.java#102...128
2. +0.70% via ...tionsController.java#68...93
3. +0.60% via ...InstanceManager.java#182...203
4. See 7 more...

Powered by Codecov. Updated on successful CI builds.

That is really hard to get right.
@bradamiller

I spent a few hours on it before. I agree that it's a feature that could be added. The events that are fired when an undo/redo event happens are the same events that this deals with so I'm not sure if the two are mutually exclusive.

I think Dirty saves is a good feature to implement until we find a suitable way to go about undo/redo operations. I think both these features should be implemented in the near future.

I agree with what @JacisNonsense said

Before merging can we add a UI indicator that the pipeline is dirty? Many apps add an asterisk after the file name in the title bar to indicate the file is dirty.

@AustinShalit How's this coming?

#647 completes this feature.